Alumni Profile: Ciera Jaspan

Thanks for taking the time to talk to us, Ciera. Can you tell us a little bit about how you found your way to computer science and software engineering?

Oddly enough, I am a computer scientist by accident. When I was growing up in California, I knew I was going to study architecture. In high school, I was looking at a list of courses and there was one where you could design a house that would actually get built. I really wanted to take this course. But my dad told me that since architects rely heavily on software, like AutoCAD, that it would be helpful to take a programming course to understand how those tools work.

I had never programmed anything. But I knew that this was a stepping stone to my dream of being an architect. My high school guidance counselor had other thoughts and told me that I couldn’t take it because I would fail; I should take a course on keyboarding instead. I wouldn’t take no for an answer and – having taken all the prerequisites – I eventually convinced them to allow me into the course.

I loved it. I was hooked. So much so that I ended up taking AP Computer Science afterwards. Never did take that architecture course, though!

And eventually you went on to California Polytechnic State University in San Luis Obispo. Did you study computer science during your undergraduate?

Yes and no. While I was an undergrad at Cal Poly, I also was working as a software engineer for a small, small consulting company called Vizolutions. I was project lead on two projects: one for a company that did software to support oil well drilling and the other developing website content management systems. It was a great experience. I was able to really get hands-on with the software process all the way from inception to delivery.

That experience changed the sort of topics I was interested in. I realized that I was never that interested in computer science theory. I knew I wanted to go to grad school, but the more I worked the more interested I became in software engineering, so much so that I changed my major from computer science to software engineering.

What did you find so interesting about software engineering?

The practicality of the field is what got me interested. I think I actually wrote that I wanted to find a way to automatically repair bugs in my code. This was something that was coming up for me at work and so it interested me. Theory is great but I was really inspired by real world problems and how to fix them here and now.

And while the practicality of software engineering is what grabbed my attention, it was the complexity of the problems that kept my interest. Computer science problems always have a “right” answer. In software engineering there isn’t a “right” answer; it is always highly dependent on the context that you are in. And more so, these problems aren’t often well-defined. I like that the first thing you have to do is ask a lot of questions about what problem you are trying to solve and what an adequate solution to that problem might look like.

And complexity is definitely present in the work that you did during your Ph.D. here at Carnegie Mellon. Can you tell us a bit more about what you studied?

It absolutely was. I studied static analysis of code that uses software frameworks. So, if someone is using one of these large software frameworks like Spring or ASP.NET, which have extremely complex APIs and protocols for how you need to use them correctly, how can we check to see that they are using the framework correctly? Oftentimes, the developers using these frameworks aren’t experts in the framework itself and so it is very easy to make mistakes.

I was focused on producing a solution that would be useful in practice. I didn’t want a solution that was perfect, that could catch all possible errors. I wanted one that had the lowest cost to use and the greatest benefit, a solution that would be most likely for developers to use in practice.

And this focus on tools which helps developers work more effectively is what landed you at Google, it seems. What do you do at Google?

When I joined Google, I came in on the Tricorder team, which is the team that runs the static analysis tools all Google developers use. So, my research at CMU was actually very related to the work I was doing. But the work at Google was interesting because it was different as well. Not only was I writing static analyses but I was also learning to run a production system on Google's infrastructure that was running these analyses across a massive codebase.

That experience, coupled with some things I picked up during my time in ISR, allowed me to move into my current role as the Tech Lead of the Engineering Productivity Research Team within the Developer Infrastructure. Developer Infrastructure is responsible for all the development tools inside Google such as our code review tool, version control system, source browsing tool, and more.

In this role, I am looking at not just static analysis tools but all developer tools across the Google ecosystem. My team is trying to better understand which tools make the developers more productive, which don’t, and where we may be missing tools.

In addition to the tools that developers use, we are also interested in their behaviors. For example, we are investigating what causes a developer to switch from working on one development task to working on something else; this is called a “context switch.” We know that some of those are interruption-based, like an email you have to respond to right away. But there are also other types of context switches, like waiting on a long-running operation.

We know that these context switches have cost. They cause a developer to lose their focus or their internal stack trace, so there is a cost associated with that movement. We are interested in exactly what causes these context switches, how often developers at Google do them, and how we can make that better.

It sounds like this sort of research has a significant sociological component to it. Is that the case?

Absolutely. And my experience here can be traced to the supportive and collaborative research community that makes up ISR. While I was doing my Ph.D., I did a couple of user studies and dabbled in this sociological approach. But where I really gained a foothold was in working alongside my peers and mentors, the other Ph.D. students and our faculty. Whether it was conversations with Brad Myers’ students about user experience or talks by Jim Herbsleb, it was this exposure to a wide range of methods that allowed me to have a rough framework for this sort of sociological research work.

What is perhaps most useful in the work that I am doing now is what I learned from Mary Shaw. Mary taught me how to approach problems. This harkens back to problem and solution definition – how do you define the problem that you are trying to solve and what a solution might look like. In my work, it is imperative that the problem be defined, that the approach match the problem, that the solution is verifiable, and that it all traces clearly back to your original problem statement. I think that is why a lot of productivity work to date has had a difficult time showing results; you can’t just throw a user study or survey at the problem without thinking about these things first. A great deal of credit is due to Mary in helping me understand how to do that.

Why is this sort of research, both in terms of tooling and developer behavior, so important right now?

This research is important because humans are expensive. At Google, we use up a lot of machine resources and that is expensive. But humans are more expensive. There is a massive amount of time, energy, and money that goes into sourcing, interviewing, hiring, and training even a single software engineer to the point of productivity. And once they are here, they are expensive to maintain in terms of keeping them happy and excited about the work they are doing. There is years of cost associated with each engineer and we can’t afford to lose them or their productivity.

So, we are extremely concerned with keeping all the engineers at Google productive and happy while doing so. The last thing we want is for someone to leave or to waste time because they are frustrated.

What do you find challenging about your work at Google?

Remember how I said that I like complex problems? Well, people are the ultimate problem in complexity! They have their own goals. Sometimes they are in conflict with others or the tools they are using. Sometimes they aren’t honest about what their goals are, either to a researcher or to themselves.

So you’re trying to figure out the real problem, and if it is a problem I can even fix. One of the biggest challenges we face comes in terms of scoping. There are lots of problems that developers deal with day-to-day but there are only some of these problems that I can realistically handle. So we have to scope these problems down in such a way that I can ask questions that will lead to a solution which will make a meaningful difference to the developer.